home *** CD-ROM | disk | FTP | other *** search
- Path: ix.netcom.com!netnews
- From: miker3@ix.netcom.com (Mike Rubenstein)
- Newsgroups: comp.lang.c
- Subject: Re: COLLEGE PROFESSORS! # 2/2
- Date: Fri, 19 Apr 1996 00:29:28 GMT
- Organization: Netcom
- Message-ID: <3176db6c.93040194@nntp.ix.netcom.com>
- References: <8BEC555.02C70031C4.uuout@sourcebbs.com>
- NNTP-Posting-Host: ix-dc6-10.ix.netcom.com
- X-NETCOM-Date: Thu Apr 18 5:29:33 PM PDT 1996
- X-Newsreader: Forte Agent .99d/32.182
-
- david.mohorn@sourcebbs.com (DAVID MOHORN) wrote:
-
- > (Continued from previous message)
- >
- >
- > return StatusSwitch
- > *** end of validation routine ***
- >
- > Clearly, example 1 is inefficient and wastes processing time by
- > continuing to check for valid data once an error is found and wasting
- > another few CPU cycles making another comparison.
- >
- > Example 2 to me seems like the best approach by returning to the caller
- > immediately once and error if found.
- >
- > Example 3 is almost as good as 2, since the nested-ifs will not continue
- > to validate data once an error is found.
- >
- > The instructors philosophy is to make it more "readable" and keep it as
- > structured as possible! As if structured programming was the only way
- > to accomplish this task. He also stated that nested ifs make the code
- > harder to read. He also stated that there is no arm in wasting a
- > few milliseconds doing the extra conditions, since it won't be
- > noticeable anyway.
- >
- > I retorted his remark and said it would on a multitasking system where
- > every cycle counts! If I were validating 10,000 data items, example 1
- > would take a considerable amount of time longer than example 2!
- >
- > Does anyone else have any opinions or horror stories?
-
- You should have a little more sympathy for your professor. Obviously,
- your poor instructor's mind has been destroyed from years of trying to
- teach students who are too stupid to post to appropriate newsgroups.
-
- In fact, what your instructor says is correct. A few microseconds (if
- you actually have a machine so slow that his method is wasting
- milliseconds you've got much bigger problems) don't make a difference
- in most programs. Clarity of code should be the main objective in
- initial coding; later, if the program is too slow you can profile it
- and find out where to optimize. Usually the clear code will be fast
- enough. Where it isn't, you'll usually find that you can make it fast
- enough by optimizing a rather small number of lines of code.
-
- It's easier to make good code fast than to make fast code good.
-
- While I don't always, or even usually, code in your instructor's
- style, most of my larger programs will have a few functions that are
- coded that way for clarity and ease of maintenance.
-
-
- Michael M Rubenstein
-